1. Statement of the Technical Field
The present invention relates to the field of server-side object-oriented programming and more particularly to custom class loaders.
2. Description of the Related Art
The class loader mechanism forms part of the foundation of the modern, virtual machine. In particular, class loaders provide the translation technology which can convert serialized byte code into named classes for execution in the virtual machine. Notably, class loaders can perform this conversion regardless of the storage means and location of the byte code. As a result, the virtual machine need not know the operational specifics associated with the file systems storing the byte code.
In conventional runtime environments like the JAVA Runtime Environment (JAVA is a trademark of Sun Microsystems of Palo Alto, Calif., United States), which enables the use and operation of computer programs coded according to the Java programming language utilizing a Java runtime environment, classes can be introduced when they are referenced by name in a class that already is executing within the runtime environment. While the entry point class of an application can require some individual processing exclusive of the class loading mechanism, subsequent attempts at loading other classes are performed exclusively by the class loader.
At its simplest, a class loader creates a flat name space of class bodies that are referenced by a string name. For example, in the case of the Java runtime environment, a class loading definition might include:Class myclass=loadClass(String className, boolean resolveclass);In this exemplary implementation of the loadClass( ) method, the variable className encapsulates a string which is understood by the class loader to uniquely identify a stored class implementation. The variable resolveclass, by comparison, is a flag which when set notifies the class loader that classes referenced by the class associated with the class name should be resolved. That is, any class referenced by the class associated with the class name should be loaded as well.
In the Java runtime environment, the virtual machine can include one class loader embedded within the virtual machine. Referred to as the “primordial” class loader, this embedded class loader automatically resolves references to class names by reference to a specified repository of trusted classes which can be run by the virtual machine without verification. Notably, in the primordial class loader, a default implementation of the loadClass( ) method can be implemented.
Earlier class loading technology permitted developers to load classes from a variety of disparate locations, including file systems, remote hosts, and the like. Yet, this type of flexibility carried the price of complexity. For example, prior to the Java 1.2 environment, customized class loaders required the implementation of the abstract loadClass( ) method. As one skilled in the art will recognize, however, the implementation of the loadClass( ) method involves significant processing, including for instance the process steps of checking whether the named class has already been loaded either by the custom class loader or the primordial loader, loading the class from the repository, defining the class, resolving the class and returning the class to the calling method.
The specification of the Java 1.2 environment, however, reduced this complexity using a parent/child delegation model in which each customized class loader delegates class loading to its parent class loader—e.g. the class loader from which the customized class loader had been sub-classed. Notably, the parent class loader either can be another customized class loader or the primordial class loader. In any case, where the parent class loader cannot load a specified class, the sub-class can attempt to locate and load the specified class using the findClass( ) method. Hence, the customized class loader is responsible only for loading those classes which are not available to the parent class loader.
Application servers permit application isolation through extensive use of customized class loading. In particular, in the virtual machine environment, each class can be defined by a class name and the class loader which loaded the class. Hence, a class can be loaded only once by a given class. Still, the same class can be loaded multiple times using separate class loaders within the same virtual machine. As a result, applications can be isolated in the virtual machine. Moreover, different versions of the same class can be utilized in different applications simultaneously.
Problems can arise, however, where classes are inter-dependent upon one another. In particular, to avoid type mismatch problems which can arise where inter-dependent classes refer to separate instances of co-dependent classes, it is imperative that each class possess a common view of their co-dependent classes. In order to overcome this problem, each inter-dependent class can rely upon a proper implementation of a class loading delegation policy facilitated by dependency definitions. Typically, these dependency definitions can be specified in a manifest file which can be accessed as part of an application archive such as a Java JAR file. Still, cyclic dependencies between classes remain problematic.
To handle cyclic dependencies, conventional custom class loaders track those class loaders which have already been visited thereby avoiding multiple class loading cycles. Notwithstanding, class loading in of itself is a computationally expensive proposition. Additionally, separately tracking the visitations of each class loader can exacerbate an already tedious process. Conventional class loaders typically address this problem by collapsing all of the dependencies into a single class loader.
Such a combination, however, can corrupt the intended dependency ordering of the component class loaders. Furthermore, replacing individual ones of the cyclically dependent classes would require the replacement of the combined class loader rather than merely the class loader associated with the replaced class. Finally, combining the class loaders into a single, combined class loader negates the advantage of application isolation provided by deploying multiple, independent class loaders.